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Abstract 

Lambda lifting is a technique for transforming a functional program with local 
function definitions, possibly with free variables in the function definitions, into a 
program consisting only of global function (combinator) definitions which will be 
used as rewrite rules. Different ways of doing lambda lifting are presented, as well 
as reasons for rejecting or selecting the method used in our Lazy ML compiler. An 
attribute grammar and a functional program implementing the chosen algorithm is 
given. 
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1 Introduction 



When compiling a lazy functional language using the technique described in [Joh84] it is 
presumed that the input program is in the form of a set of function definitions, possibly 
mutually recursive, together with an expression to be evaluated and printed as the value 
of the program. That is, programs are of the form 

flXi...X ni C\ 



where the function bodies e 4 - do not contain any lambda expressions, but may contain local 
definitions with let and letrec. To summarise the technique, each function definition 



is compiled into code for an abstract graph reduction machine, called the G-machine, that 
performs the graph rewriting 

f C\...C m =^ 6 [ci . . . G m jx\ . . .X m ~^ 

i.e., the graph of an application of the function / is rewritten into the graph for the value 
of the right hand side, substituting actual parameters e 4 - for formal parameters X{. 

Although recursive equations as above are a powerful programming language in their 
own right, for convenience and program clarity it is an advantage to be able to write 
lambda expressions and locally defined functions. 

If we introduce expressions with local function definitions, like 

let f x = x*x in ... f ... 

the compiler would in principle be able to move the function definition out to the global 
level. Similarly, the compiler would transform the lambda expression \x.x*x into the 
expression / and also move the function definition fx = 21*21 to the global level (/is a new 
unique identifier). 

This simple scheme of course breaks down if the function body contains free variables; 
a free variable y as in the function definition fx = ...y... would be undefined when the 
definition is moved to the global level. 

Dealing with these free variables in function definitions is the main subject of this pa- 
per. The process of flattening out a program involving local function definitions, possibly 
with free variables, into a program consisting only of global function definitions, we call 
lambda lifting. As we proceed in our discussion, we will make choices which depend of the 
particular idiosyncrasies of the G-machine. The algorithm described at the end of this 
paper is used in a compiler for Lazy ML } LML for short, developed by L. Augustsson and 
myself. Further details on the compiler can be found in the papers [Aug84, Joh84, Aug85]. 

2 Different strategies for the transformation 

2.1 Attempt 1: Translate everything into lambda expressions 

In dealing with programs containing lambda expressions, each lambda expression could be 
lifted out to become a global function (rewrite rule). (In what follows Xx.Xy.e is treated as 




fx\...x 



m 



= e 
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one lambda expression introducing two variables, rather than two nested lambda expres- 
sions. A definition like f x y = e is equivalent to f = Ax.Ay.e.) Before this can be safely 
done it is necessary to abstract the free variables from each lambda expression using the 
transformation rule 

Xx.e =>■ (Xy.Xx.e)y 

i.e. beta substitution backwards, for each free variable y in e. The following example 
illustrates the idea. 

(Ay.f(Ax.y))5 
iAv.fiU^Ax^viio 

F 

G 

Now the innermost lambda expression indicated by is given the name F and made 

F 

into a global function; the same thing is done with the outermost one yielding: 

G 

def: F y x = y 
def: G y = f (F y) 
expr: G 5 

LML and many other functional languages allow expressions with local definitions. The 
traditional way of dealing with local nonrecursive and recursive definitions (let and le- 
trec), both in defining their meaning and in implementations, is to treat them as syntactic 
sugaring for lambda expressions and the fix-point combinator Y [Lan66] [Tur79] [Hug82]. 
The following two transformation rules are then used. 

let x = e\ in e 2 =>■ (Xx.e 2 )ei 

letrec x = e\ in e 2 =>- let x = Y(Xx.ei) in e 2 

The resulting expression contains lambda expressions in place of the lets and letrecs, 
and can then be treated as described before. The following example illustrates this. 

let i = 5 in letrec f = Ax.f i in f i =>■ { remove recursion } 
let i = 5 in let f = Y(Af.Ax.f i) in f i => { remove let } 
(Ai.(Af.f i)(Y (Af.Ax.f i))) 5 =>■ { abstract free variables } 
(Ai. ((Ai.Af.fi) i) (Y ((Ai.Af.Ax.fi) i))) 5 

Giving names to the lambda expressions, and lifting them to the global level yields the 
following program. 

def: F i f = f i 

def: G i f x = f i 

def: H i = (F i) (Y (G i)) 

expr: H 5 

Treating expressions involving let and letrec in the manner just described is unsatisfac- 
tory for several reasons: 
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• For efficiency reasons we want a recursive function in the source program to remain 
recursive in the transformed program, since the LML compiler and the G-machine 
can deal with global recursive functions. Eliminating the recursion by using the 
fix-point combinator Y thus introduces unnecessary inefficiencies. 

• Let and letrec expressions that involve no lambda expressions need not be tran- 
formed further. They can be directly compiled into G-machine code that constructs 
or evaluates a shared or cyclic expression graph. 

• The effect of this transformation scheme is that every free variable that occurs inside 
a lambda expression has to be abstracted out of the lambda expression and passed 
as a function argument all the way down to the place of usage. But if the right hand 
side of the definition is a lambda expression we would prefer to treat the definition 
as a global function constant whose occurrence thus would not need to be abstracted 
out. 

Therefore we will turn our attention to lambda lifting schemes that allow us to keep 
recursion, let and letrec as far as possible. 

2.2 Attempt 2: Keep let and letrec 

In our next attempt, we keep the let and letrec expressions in the program, but otherwise 
proceed as before with the lambda expressions. For example, in 

let i = 5 in letrec f = Ax.f (i+i) in f (i*i) 

both / and i are free in the lambda expression, and so are abstracted out: 

let i = 5 in letrec f = (Af.Ai.Ax.f (i+i)) f i in f (i*i) => 

def: F f i x = f (i+i) 

expr: let i = 5 in letrec f = F f i in f (i*i) 

Unfortunately, this modified strategy suffers from some of the same drawbacks as in the 
first attempt, namely that local function definitions (i.e. definitions where the right hand 
side is a lambda expression) are treated as all other definitions: variables are passed as 
arguments and their occurences inside other lambda expressions are abstracted out of the 
lambda expressions. In the example above this happened with the variable /, which was 
abstracted out of the definition of /. As a consequence, the resulting global function is 
still not recursive. 

Another drawback of this scheme concerns the efficiency of function application in 
the G-machine setting. When it comes to evaluation of the application / in the 

example above / has the value of an unreduced curried application of F (one argument 
of F is missing in F f i to be able to reduce it), and one has to revert to worst-case 
treatment of the application. On the other hand if the function being applied is a global 
one, or its graph value is a function node only, and has the same number of arguments as 
formal parameters, it is possible to evaluate the application much more efficiently. In this 
particular example f(i*i) is a tail call. Since /is a variable here, we know of no essentially 
better simpler way to implement the tail call than to than to build the graph for f(i*i) the 
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hard way. But if /were a global function with arity 1, then the call can be implemented 
much more efficiently with an assignment i := graphfor(i*i) followed by a jump to the 
code for / — see [Joh84] for details. It is also more efficient to build the graph for an 
application if the function is a global one and the number of argument is the same as the 
number of formal parameters. In that case we can build a vector application node instead 
of a chain of apply nodes. 

We aim for a strategy where the local function definitions can be lifted out to the 
global level to become global function constants, so that their occurrences need not be 
abstracted out, even in the presence of free variables in the function definitions. 

2.3 Attempt 3 

The trouble with attempt 2 is that after having abstracted out free variables from a local 
function definition, the right hand side of the function is no longer a lambda expression, 
because the lambda expression is applied to the abstracted variables. In our third attempt, 
we instead perform abstraction as follows: 

• For each free variable in a local function definition, add an argument to the function 
(by lambda abstraction) as before. The function names themselves are treated as 
constants, and need not be abstracted out. 

• Apply the same free variables to each use of the function, substituting fx\...x n for 
/, where x\...x n is the set of free variables in the definition of /. (If we make all 
identifiers unique before the whole lambda lifting process starts, no name clash can 
occur.) 

So the only difference between version 2 and version 3 of our lambda lifting strategy is the 
place where the abstracted variables are passed as arguments. In version 2 the lambda 
expression of the function definition is applied to the abstracted variables, in version 3 
each use of the function is applied to the abstracted variables. But as we shall see, this 
little difference will have far-reaching effects. 
In our example 

let i = 5 in letrec f = Ax.f (i+i) in f (i*i) 
the variable i is free in the definition of /, and we get 

let i = 5 in letrec f = Ai.Ax.f i (i+i) in f i (i*i) 

Finally, / can be safely lifted out to become a global function constant: 1 

def: f i x = f i (i+i) 
expr: let i = 5 in f i (i*i) 

Let us try our new strategy on a nastier example, involving two mutually recursive 
function definitions, with different free variables in each of them. 

1 Incidentally, the definition i=5 could also be made global, but here we keep it in the expression 
merely to introduce i as a free variable. 
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let a = ... and b = ... 

in letrec f = Ax. ... a ... g ... 

and g = Ay. ... b ... f ... 

in ... f ... g ... 

The variable a is free in /, and b is free in g } so if we apply our new lambda lifting strategy 
here, we get: 

let a = ... and b = ... 

in letrec f = Aa.Ax. ... a ... g b ... 

and g = Ab.Ay. ... b ... f a ... 

in ... f a ... g b ... 

This step unfortunately introduced the variable b in / and a in g } and the function defini- 
tions cannot yet be lifted out because of these new free variables. So the lambda insertion 
step has to be repeated: 

let a = ... and b = ... 

in letrec f = Ab. Aa.Ax. ... a ... gab ... 

and g = Aa. Ab.Ay. ... b ... f b a ... 

in ... f b a ... gab... 

Neither / nor g now contain free variables, so finally we get the global functions, and 
expression: 

def: f b ax = ... a ... g a b ... 
def: g a b y = ... b ... f b a ... 

expr: let a = ... and b = ... in ... fba ... gab ... 

From this example it is obvious that if we adopt this abstraction method in our lambda 
lifting algorithm, the lambda-insertion-and-application has to be repeated until no free 
variables remain inside lambda expressions. It does not take such a complicated (and 
perhaps contrived) example as the one above to make repetition necessary. Consider the 
following one, which is not even recursive. 

let x = ... 

in let f = Ay. ... x ... 
in let g = Az. ... f ... 
in ... f ... g ... => 

let x = ... 

in let f = Ax. Ay. ... x ... 
in let g = Az. ... f x ... 
in ... f x ... g ... => 

let x = ... 

in let f = Ax. Ay. ... x ... 
in let g = Ax.Az. ... f x ... 
in ... f x ... g x ... 
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Performing lambda lifting in a compiler by repeatedly transforming the program in this 
manner is very costly. But it is possible to find the set of variables that has to be 
abstracted out from each function, in a less costly manner. 

Let Ej denote the set of variables that has to be abstracted out of the definition of /. 
Then for each function definition we can set up an equation involving Ej, E g etc. The 
resulting system of set equations can then be solved with respect to Ej, E g etc. Again 
let us have a look at the 'nasty' example. 

letrec f = Ax. ... a ... g ... 
and g = Ay. ... b ... f ... 
in ... 

Ej obviously contains a, but also the variables that g will be applied to, i.e. the free 
variables of g. The two set equations we obtain from the example above are the following. 

Ej = {a} U E g 

E g = {b} U E f 

We now proceed to solve these equations. Substituting the first equation into the second 
we have 

E g = {b} U ({a} U E g ) 
E g = {a, b} U E g 

which has the least solution 

E g = {a,b}. 

and from the first equation we get 

Ef = {a,b} 
The above solutions now instruct us to 

• add Aa.Ab. ... to the definition of /, 

• substitute fab for /, 
and similarly for g. 

Solving the above set equations is equivalent to computing the transitive closure C* 
of the relation C, where fCg is true if the function / has an occurrence of the function 
name g. Then each Ej is obtained by 

Ef={JS g 

g ex 

where X = {h | fC*h} 

and S g is the set of free variables in the function g. 

The best time complexity known for the transitive closure problem is 0(n 3 ) [AHU76] 
and that will also be the worst case complexity of our lambda lifting algorithm (n is 
the number of functions in the program) if all the equations for all the functions in the 
program are solved in one go. 

But in general the situation is not quite as bad as that. In the previous example 
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let x = ... 

in let f = Ay. ... x ... 
in let g = Az. ... f ... 
in ... f ... g ... 

we can see that /cannot contain g because of the scope rules of the language, so Ej = {x} 
can be obtained directly without having to solve any set equations. Thus we can proceed 
top-down in the program to be lambda-lifted, and invoke the set equation solving ma- 
chinery only for each set of mutually recursive function definitions in a letrec expression. 

3 The lambda lifting algorithm 

The lambda lifting algorithm that we finally adopt is based on solving set equations as 
described in the previous section. 

1. Give all identifiers a unique name. (This is done early in the LML compiler, and is 
called the scope analysis.) This will avoid name clashes when doing the substitutions 
in step 4. Handling the set equations is also simplified if all functions have distinct 
names. 

2. Anonymous lambda expressions (i.e. those not being the right hand side of a defini- 
tion) are given names, substituting let/ = Xx.Xy...e in/ for Xx.Xy...e } where in each 
case / is a new unique identifier. The purpose is to let these lambda expressions 
take part in the same equation solving machinery as the function definitions, and 
to give them the names they will have as global functions. 

3. Traverse the program top-down. At each letrec expression 

letrec fiXn...x lmi = e 1 

defined functions 

v 1 = e\ 

defined variables 

in e 

compute the set of variables to be abstracted out of the defined functions, as follows. 

At this point we know three items obtained previously in the top-down traversal of 
the program: 

vars: is the set of variables in the current scope, i.e. they can occur as free variables 
in the letrec expression. At the start of the lambda lifting process this set is 
empty. 

funs: is similarly the set of functions in the current scope; for these functions we 
already know which variables that has to be abstracted out of the functions. 
Initially this set is also empty. 
sol: is the solutions of the set equations for the function names in the set funs. 
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(a) 



Each of the functions fi yields a set equation 



E h = S fi U E g U E h U ... 



where 



{g,h,...} = {f u ...f n }nfi( ei ) 

S h = (({v 1} ...v m } U vars) C]fi(e t )) U £ 3l U ... U £, 
{9\, —9n} = funsnfi(ei) 
fi(ei) = the free identifiers in e 4 - 



The functions g,h, ... are the ones defined in the currently processed definition 
list. The functions g\...g n are the functions defined on an outer level, and E 9i 
comes from the solutions in sol. Note that if the definitions are not recursive 
then the set {g, /i, ...} above is empty and we have the solution Ej t = Sj i 
directly. 



(b) 
(c) 



Solve the set equations, for example by repeated substitution. 



Continue down in the program tree, with 



vars := vars U {v i} ...v m } 
funs := funs U ...f n } 
sol :=sol@[(f 1 ,E h ) ] ...(f n ,E fn )] 



4. For each Ej t = {xi 7 ...x m } from the solution of the set equations, perform the 
following substitutions in the program: 

• in the definition of ff. fi = e=? fi = \x\...\x m .e 

• for each occurence of ff. fi fiX\...x m . 

5. Lift out the functions to the global level. If a definition list then becomes empty, 
substitute let in e e, and similarly for letrec. 

What can be said about the complexity of this algorithm? Solving the set equations at 
each letrec expression has complexity 0(n 2 ) set operations, or 0(n 3 ) 'basic' operations, 
where n is the number of functions in the definition list. The rest of the algorithm is 
linear in the number of set operations, or 0(n 2 ) 'basic' operations, where n here is the 
size of the program. 

4 An attribute grammar and a functional program 
for lambda lifting 

In this section we elaborate the lambda lifting algoritm in further details and present it in 
the form of an attribute grammar for the steps 3-5 in the previous section. This attribute 
grammar is then translated into a functional program evaluating the attributes. A further 
discussion of attribute grammar based functional programming can be found in [Joh87]. 

An attribute grammar can be thought of as a decoration of the parse tree with name- 
value pairs. Normally, the parse tree has been constructed (implicitly or explicitly) during 
parsing of the input string of lexical symbols. However, when presenting the attribute 
grammar for lambda lifting, instead of writing the attribute definitions in conjunction 
with the production rules of a context free grammar, we will write them in conjunction 
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with patterns that match nodes in the abstract syntax tree. For instance, instead of a 
production rule 

e\ — y letrec d in e 2 attribute definitions 

we will write 

E = LETREC (d,e) attribute definitions 

where the variables E } d and e correspond to nonterminals with attributes being assigned 
to them. The pattern LETREC (d,e) will appear in the function that evaluates the at- 
tributes. 

We will deal with abstract syntax trees generated by the following LML type declara- 
tions: 

Expr = LETREC(list(Def) # Expr) + APPL(Id # list(Expr)) 
Def = VAR(Id # Expr) + FUN(Id # list(Id) # Expr) 

For the sake of simplifying the discussion, we consider only recursive local definitions, 
as non-recursive ones are a degenerate case — no solving of set equations is necessary. 
APPL is curried application of an identifier to a list of expressions. A definition is either 
a variable definition ( VAR) or a function definition (FUN) where the list of identifiers are 
the formal parameters of the function. The table below summarizes the cases that will 
be considered in the attribute grammar. 



E 


= LETREC(d,e) 


local recursive definition expression 


E 


= APPL(f,a) 


curried application expression 


A 


= e.a 


non-empty argument list 


A 


= [] 


empty argument list 


D 


= VAR(i,e).d 


variable definition in a definition list 


D 


= FUN(f,I,e).d 


function definition in a definition list 


D 


= [] 


empty definition list. 



Thus variables E and e denote expressions, A and a denote argument lists, i.e. lists of 
expressions, and D and d denote definition lists. 

The set operations used in the lambda lifting algorithm are the following: 

Mkset : list (Id)— > list (Id) make a "set" of Ids from a list of Ids 

U : list(Id)— J- list(Id)— J- list(Id) U (union) 

Is : list(Id)— > list (Id)— » list(Id) C\ (intersection) 

Mem : Id— > list (Id) — ^ bool £ (membership) 

We use lists instead of sets for the following reasons. The order of the identifiers in such 
a set is important in step 4 of the algorithm: the variables must of course be in the same 
order when abstracting them out of the function definition, as they occur when the func- 
tion is applied to them. This can be achieved for example by letting the "set" operations 
maintain the list sorted (and without duplicates). Also, it is frequently convenient to 
actually treat the set as a list being concatenated, traversed by map etc. As a concession 
to readability we will use the conventional symbols U, H and £ for union, intersection an 
set membership respectively. We will also use 0 to denote the empty set (list), and {x} 
to denote singleton sets (lists). 
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The entities vars } funs and sol of the previous section are the inherited (i.e. propagating 
downwards in the tree) attributes of the attribute grammar. We have the following 
synthesized (i.e. propagating upwards) attributes: 

ids: the set of identifiers occuring in the the expression or expression list or definition 

list, as applicable. 
lifted: a list of lifted function definitions, 

expr: the new expression (or expression list, or definition list, as applicable) where the 
lifted functions have been removed. 

Furthermore, as a mere programming convenience when constructing the set equations, 
we have three additional synthesized attributes defined for definition lists: 

dvars: the variables defined in the definition list, 
dfuns: the functions defined in the definition list, 

ss: a list of pairs of function names and the identifiers occuring in each definition. 

Below we give the attribute grammar in its entirety, one attribute at a time. Our notation 
for an attribute ids of E } say, is E'ids. 



E 




LETREC(d,e): 


: E'ids = 


d'ids U e'ids 


E 




APPL(f,a): 


E'ids = 


{f} U a'ids 


A 




e.a: 


A'ids = 


e'ids U a'ids 


A 




[]; 


A'ids = 


0 


D 




VAR(i,e).d: 


D'ids = 


e'ids U d'ids 


D 




FUN(f,I,e).d: 


D'ids = 


e'ids U d'ids 


D 




[]: 


D'ids = 


0 


E 




LETREC(d,e): 


: E'lifted 


= d'lifted @ e'lifted 


E 




APPL(f,a): 


E'lifted 


= a'lifted 


A 




e.a: 


A 'lifted 


= e'lifted @ a'lifted 


A 




[]: 


A 'lifted 


= [] 


D 




VAR(i,e).d: 


D 'lifted 


= e'lifted @ d'lifted 


D 




FUN(f,I,e).d: 


D 'lifted 


= FUN(f, lookup D'sol f @ I, e'expr) . e'lift. 


D 




[]: 


D 'lifted 


= [] 


E 




LETREC(d,e): 


: E'expr = 


= if d'expr=[] then e'expr else LETREC(d'i 


E 




APPL(f,a): 


E'expr = 


= APPL(f, toexpr(lookup E'sol f) @ a'expr) 










where toexpr = map(Ai.APPL(i,[])) 


A 




e.a: 


A'expr = 


= e'expr . a'expr 


A 




[]: 


A'expr = 


= [] 


D 




VAR(i,e).d: 


D'expr : 


= VAR(i, e'expr) . d'expr 


D 




FUN(f,I,e).d: 


D'expr : 


= d'expr 


D 




[]: 


D'expr : 


= [] 



d'lifted 
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E 

E 
A 

D 

D 



E 
A 

D 

D 



E 
A 

D 

D 



D 
D 
D 

D 
D 
D 

D 
D 
D 



LETREC(d,e) 
APPL(f,a): 



e.a: 



VAR(i,e).d: 
FUN(f,I,e).d: 



d'vars 
e'vars 
a'vars 
e'vars 
a'vars 
d'vars 
e'vars 
e'vars 
d'vars 



E'vars U d'dvars 

E'vars U d'dvars 

E'vars 

A'vars 

A'vars 

D'vars 

D'vars 

D'vars U Mkset(I) 
D'vars 



E = LETREC(d,e): d'funs = E'funs U d'dfuns 
e'funs = E'funs U d'dfuns 
a'funs = E'funs 
e'funs = A'funs 
a'funs = A'funs 
d'funs = D'funs 
e'funs = D'funs 
e'funs = D'funs 
d'funs = D'funs 



APPL(f,a): 
e.a: 

VAR(i,e).d: 
FUN(f,I,e).d: 



(4) E = LETREC(d,e) 



d'sol = nsol 
e'sol = nsol 
where nsol 



solve (map ( A (f , S ) .f , 

Xset E'sol 



d' 



ss 



(S n E'funs) 

(S n (E'vars U d'dvars)), 
(S n d'dfuns) 
@ E'sol 



APPL(f,a): 
e.a: 

VAR(i,e).d: 
FUN(f,I,e).d: 



VAR(i,e).d: 
FUN(f,I,e).d: 



VAR(i,e).d: 
FUN(f,I,e).d: 



VAR(i,e).d: 
FUN(f,I,e).d: 



a'sol 
e'sol 
a'sol 
d'sol 
e'sol 
e'sol 
d'sol 

D'dvars 
D'dvars 
D'dvars 

D'dfuns 
D'dfuns 
D'dfuns 



E'sol 
A'sol 
A'sol 
D'sol 
D'sol 
D'sol 
D'sol 



{i} U d'dvars 
d'dvars 



d'dfuns 

{f} U d'dfuns 



D'ss 
D'ss 
D'ss 



d'ss 

(f,e'ids).d'ss 
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The meat of the algorithm is contained in the places marked (l)-(4). In (1) the function 
definition is put in the list of lifted functions (note in (3) that the functions will be absent 
in the resulting expression, attribute expr). At (2) and also in (1) the substitutions of step 
4 is performed, where the solutions of the set equations for / is obtained by looking it up 
in the attribute sol. Note that we always perform this lookup even if the identifier is not a 
function in our sense (i.e. a definition where the right hand side is a lambda expression). 
Thus when / is not a function lookup must return an empty "set". The function lookup 
can be defined as follows. 

lookup ((f,s).sol) i = if f=i then s else lookup sol i 
|| lookup [] i = [] 

At (4) the steps 3(a) - 3(c) are performed. The set equations for a definition is obtained, 
solved, and the solution appended to the previously obtained solution. A set equation 

E h = S fi U E g U E h U ... 
is represented by a triple 
(/«■> S fi> {9-, h, •••}). 

A list of such triples, one for each function in the definition list, is constructed from the 
ss attribute of the definition list. The expression 

Xset E'sol (S n E'funs) (S n (E'vars U d'dvars)) 

computes 

(({ui, ...v m } U vars) n /i(e,-)) U E gi U ... U E 9n 

of step 3(a). the function Xset can be defined as follows. 

Xset sol (f.l) z = lookup sol f U Xset sol 1 z 
|| Xset sol [] z = z 

The function solve solves the set equations. One possible formulation of solve which solves 
by repeated substitution is given below (see next page for the definitions of map and itlist). 

solve [] = [] 
|| solve ((f,s,e).Q) = [(f,s)] 

|| solve ((f,s,e).l) = let sol = solve(map(A(fl,sl,el).if f £ el 

then (fl, s U si, e U el) 
else (fl, si, el)) 1) 
in (f, itlist (Ax.Ap. lookup sol x U p) e s).sol 

Finally, below we give a functional program for doing lambda lifting, by evaluating at- 
tributes as defined in the attribute grammar above. The function Lambdalift contains 
the auxiliary functions Le, La and Ld doing the actual work in traversing the abstract 
syntax tree and evaluating the attributes. Apart from taking the tree as an argument, 
they also take as arguments the inherited attributes, and return a tuple of the synthe- 
sized attributes. Thus Le takes an expression, La takes an expression list and Ld takes a 
definition list as an argument. They also take as arguments the inhertied attributes vars, 
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funs and sol. Le and La returns a triple of the attributes expr } lifted and ids. Ld returns 
a 6-tuple of the attributes expr } lifted, ids, dvars, dfuns, and ss. 

Note that although the attribute grammar describes a multipass algorithm, the result- 
ing program traverses the abstract syntax tree only once. Note also the unconventional 
use of recursion resulting from this method of evaluating attributes, which is particu- 
larly conspicuous in the case Le(LETREC(d,e)). Components 4-6 of what Ld returns is 
used to compute the set equations for the functions defined in this definition list. These 
equations are solved, the extended set of solutions nsol passed further down in the tree, 
where Le, La and Ld uses it to compute the first and second component of the tuple. 
Circular programs such as this one requires lazy evaluation to work. A discussion of such 
programming techniques can be found in [Bir84] and in [Joh87]. 
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Lambdalift expr = 

let Xset sol s z = itlist(Af.Ap.U (assocdef f sol []) p) s z in 
letrec solve [] = [] 

|| solve ((f,s,e).[])=[(f,s)] 
|| solve ((f,s,e).l) = 

let so = solve(map(At. let (fl,sl,el) = t 

in if Mem f el then (fl, U s si, U e el) else t) 1) 
in (f, itlist (Ax.Ap. U (assocdef x so []) p) e s).s 

in 



letrec Le (LETREC(d,e)) vars funs sol = 

letrec (ed,dd,id,dvars,dfuns,ss) = Ld d nvars nfuns nsol 
and (ee,de,ie) = Le e nvars nfuns nsol 
and nvars = U vars dvars 
and nfuns = U funs dfuns 

and nsol = solve(map(A(f,S). f, Xset sol (Is S funs) (Is S nvars), Is S dfuns) ss)@sol 
in ((if ed=[] then ee else LETREC(ed,ee)), de@dd, U id ie) 
|| Le (APPL(f,E)) vars funs sol = 

let (eE,dE,iE) = La E vars funs sol 

in (APPL(f,map(Ai.APPL(i,[])) (assocdef f sol []) @ eE), dE, U [f] iE) 



and La [] vars funs sol = ([], [], []) 
|| La (e.l) vars funs sol = 

let (ee,de,ie) = Le e vars funs sol 
and (el,dl,il) = La 1 vars funs sol 
in (ee.el, de@dl, U ie il) 



and Ld [] vars funs sol = ([], [],[],[],[], []) 
|| Ld (VAR(x,e).l) vars funs sol = 

let (ee,de,ie) = Le e vars funs sol 
and (el, dl,il, dvars, dfuns, ss) = Ld 1 vars funs sol 
in (VAR(x,ee).el, de@dl, U ie il, U [x] dvars, dfuns, ss) 
|| Ld (FUN(f,I,e).l) vars funs sol = 

let (ee,de,ie) = Le e (U vars (Mkset I)) funs sol 
and (el, dl,il, dvars, dfuns, ss) = Ld 1 vars funs sol 

in (el, FUN (f, assocdef f sol [] @ I, ee).de@dl, U ie il, dvars, U [f] dfuns, (f, ie).ss) 



in let (newexpr, liftedfuns, $) = Le expr [] [] [] 
in LETREC (liftedfuns, newexpr) 

Library functions 
map f [] = [] 
|| map f (x.l) = f x. map f 1 
and itlist f [] z = z 

|| itlist f (x.l) z = f x (itlist f 1 z) 
and assocdef x [] def = def 

|| assocdef k ((x,y).l) def = if k = x then y else assocdef k 1 def 
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